Sebastian Keller [Sat, 25 Dec 2021 23:19:25 +0000 (00:19 +0100)]
messageTray: Close SHOWING banner when its notification is destroyed
Currently only banners in the SHOWN state are hidden when the underlying
notification is destroyed, but if they are in the SHOWING state, they
remain visible. Because the 'notification' member has already been set
to null when the notification got destroyed, closing the banner by
clicking on the close button, will not do anything and clicking on the
notification itself will result in an error message. For notifications
without a timeout, i.e. critical ones, this will result in an
uncloseable notification.
This can happen if the program creating a critical notification
immediately closes it again, as might happen with power notifications
from gnome-settings-daemon in some situations.
Florian Müllner [Wed, 5 Jan 2022 01:42:49 +0000 (02:42 +0100)]
environment: Require libgweather 3.0
GWeather did a major version bump on its main branch, so it is
now possible that multiple versions are installed in parallel,
and we should explicitly pick the one we are using.
kyte [Sat, 27 Nov 2021 07:50:23 +0000 (13:20 +0530)]
lockScreen: Don't wake up screen in DND mode
Screen woke up whenever a new notification popped up
on lock screen even when DND was turned on.
This commit changes this behaviour to not wake
the screen up in such case.
Sergio Costas [Sat, 18 Dec 2021 23:05:21 +0000 (00:05 +0100)]
workspaceAnimation: Make WorkspaceGroup public
The WorkspaceGroup class in defined as CONST, which means that,
strictly speaking, is inaccessible from outside the file
workspaceAnimation.js. But Desktop Icons NG needs access to it.
Although the current Javascript engine "tolerates" this access,
a warning message is shown in the log advertising that it's
incorrect, and that although it is still allowed, the code
should be fixed.
This patch changes the definition from CONST to VAR to allow
accessing it from extensions.
Sebastian Keller [Wed, 17 Nov 2021 01:50:39 +0000 (02:50 +0100)]
util: Properly handle markup in highlighter
The code to highlight matches did not properly escape the passed in text
as for markup before adding its highlighting markup. This lead to some
search result descriptions not showing up, because their descriptions
contained characters, such as "<", that would have to be escaped when
used in markup or otherwise lead to invalid markup.
To work around this some search providers wrongly started escaping the
description on their end before sending them to gnome-shell. This lead
to another issue. Now if the highlighter was trying to highlight the
term "a", and the escaped description contained "'", the "a" in
that would be considered a match and surrounded by "<b></b>". This
however would also generate invalid markup, again leading to an error
and the description not being shown.
Fix this by always escaping the passed in string before applying the
highlights in such a way that there are no matches within entities.
This also means that search providers that escaped their description
strings will now show up with the markup syntax. This will have to be
fixed separately in the affected search providers.
Daniel van Vugt [Thu, 16 Dec 2021 07:28:20 +0000 (15:28 +0800)]
windowManager: Use one consistent animation mode for minimize/unminimize
Firstly don't use EASE_IN for any minimize/unminimize animations because
those start slow and end fast. The effect of that was minimize/unminimize
appearing to be unresponsive to user clicks for a little while before
accelerating away. All such animations should be EASE_OUT for an immediate
response followed by deceleration at the end.
Secondly we replace the shallow 200ms QUADratic curves with a steeper
400ms EXPOnetial curve. Because it's steeper and twice as long the fast part
feels the same as 200ms QUAD, but there's an extra 200ms after that in which
to slow down smoothly giving a more fluid appearance. No sudden stops.
Daniel van Vugt [Thu, 16 Dec 2021 07:36:43 +0000 (15:36 +0800)]
windowManager: Unminimize a window to its buffer rect geometry
If you slow down the unminimize animation you will notice it overshoots and
then snaps back, but only for decorated windows. Undecorated windows would
unminimize to their correct position. So we remove decorations from the
equation and now all window types unminimize to their correct position.
This wasn't noticeable because the unminimize animation velocity is usually
so high at the end (EASE_IN_EXPO) that there are no frames rendered near the
end of the curve to show it had overshot.
This appears to be consistent with the Mutter source - associating the
actor geometry with `buffer_rect` and not `frame_rect`. See
`meta_window_actor_sync_actor_geometry` for example.
Related to: https://bugzilla.gnome.org/show_bug.cgi?id=786789#c1
Florian Müllner [Wed, 22 Dec 2021 00:53:17 +0000 (01:53 +0100)]
shell/app: Re-order running-state cleanup
Since commit 1807be1, we clear the fallback icon when a window is
removed, and notify the icon change. The notify call currently
happens after removing the window from the running state, but
before syncing the state (and possibly clear the running state
altogether).
That state is inconsistent and results in an assertion hit when
some code tries to re-fetch the icon in response to the notify
call.
Address this by updating the state before clearing the fallback
icon, so that the app will be in the correct STOPPED state after
removing the last window.
Sebastian Keller [Mon, 20 Dec 2021 22:15:40 +0000 (23:15 +0100)]
st/scroll-view-fade: Simplify shader a bit
The shader was using too many ALU instructions for Intel 945GM hardware,
so simplify it a bit. The resulting math is the same, but a few
redundant operations have been removed.
Benjamin Berg [Wed, 15 Dec 2021 15:03:52 +0000 (16:03 +0100)]
shell/app: Correctly track the window used for the fallback icon
We were not properly tracking the window used for the fallback icon.
This could trigger a crash, as disconnection of the signal handler might
happen on the wrong window, which in turn could cause the icon change
notification to happen on a destroyed ShellApp instance.
Fix this by tracking the window used for the fallback icon. Disconnect
the icon notify callback explicitly for this window only when it is
removed.
Also, just to be extra safe, make sure that the icon is never NULL even
if x11_window_create_fallback_gicon should return NULL for some reason.
Florian Müllner [Tue, 16 Nov 2021 19:46:58 +0000 (20:46 +0100)]
shell/window-tracker: Track ::window-created
We currently track windows via MetaWorkspace's ::window-added and
::window-removed signals. Those aren't emitted for override-redirect
windows though, as those aren't actually located on any workspace
(see https://gitlab.gnome.org/GNOME/mutter/-/blob/gnome-41/src/core/window.c#L1322).
While that shouldn't be an issue as there's no good reason to look up
the ShellApp of an OR window, extensions can make modifications that
result in OR windows ending up in places that assume that every window
has an associated ShellApp.
We can either
- accept that extensions break stuff (including badly)
- carefully handle app-less windows everywhere
- extend tracking to OR windows
Opt for the last option, as that's the most user-friendly and least
disruptive one.
It's also simpler to track ::window-created and ::unmanaged, as we
don't have to track workspaces or windows moving between workspaces.
Florian Müllner [Tue, 16 Nov 2021 19:52:11 +0000 (20:52 +0100)]
shell/window-tracker: Track windows getting unmanaged
It makes sense to not rely on workspaces' ::window-removed
signal, and we already do that in ShellApp.
However it is odd to remove a tracked window from the app,
but still track it in the window tracker. Move the code
to remove unmanaged windows from both.
Florian Müllner [Thu, 11 Nov 2021 17:40:42 +0000 (18:40 +0100)]
shell/window-tracker: Do not filter tracked windows by type
The window-type property may change, and with it the skip-taskbar
property that decides whether we consider it "interesting".
As a result we can end up showing untracked window, i.e. one
which does not have an associated app.
Cover this case by simply tracking all windows regardless of
their type. This won't change the app's running state, as that
is solely based on the skip-taskbar property (which is enforced
for all previously excluded window types).
Sebastian Keller [Tue, 23 Nov 2021 01:48:04 +0000 (02:48 +0100)]
util: Wait for initial name owners in DBusSenderCheck before checking
Otherwise an allowed caller might get rejected if the call is right
after a gnome-shell restart and the watchers have not finished running
their callbacks yet.
Dylan McCall [Mon, 29 Nov 2021 00:19:35 +0000 (16:19 -0800)]
messageList: Give focus to next message on delete
When the user deletes a message using the keyboard, set the keyboard
focus to the next message, or to the list container itself, so it
remains possible to navigate using the keyboard.
calendar-server: Remove the all-day property of events
The way it is currently calculated is broken for days with DST changes
or leap seconds and it is not needed anymore anyway. This will also make
the fix in the following commit simpler.
Given the correct end date this code would be able to determine this
correctly itself and doesn't need to rely on that property. And events
without correct end dates are currently not shown anyway. This prepares
for removing the allDay property entirely.
This also fixes events going from 13:00 the current day to 01:00 not
showing "...". It also fixes multi-day events wrongly detected as
all-day events by the calendar-server showing up as "All day", despite
only covering 1 hour of the day.
Events with a date time (not just a date) where the end time is missing
or matching the start time were considered to not overlap the selected
interval if they were happening on the start time of the interval. This
was causing such zero-length events to be omitted from the calendar if
they were starting at 0:00.
calendar: Start ranges at 0:00 and iterate in whole days
Using a starting time other than 0:00 will prevent events before the
chosen starting time from showing up for that range. This was causing
events before 12:00 to be missing in the shell calendar on the first day
of a range.
Fix this by always starting at 0:00 and then incrementing by days rather
than a time value that depending on DST or leap seconds may or may not
correspond to a day.
dateMenu: Use intervals with non-inclusive ends for date ranges
The ical events, we are comparing these intervals to use the first point
in time after the end of the event as their end time, while the code in
gnome-shell was using the last point in time within the range. This was
causing multi-day events ranging from 0:00 to 0:00 to have a trailing
"..." shown on the last day.
Florian Müllner [Tue, 23 Nov 2021 19:19:14 +0000 (20:19 +0100)]
main: Warn when unsafe mode is toggled
MetaContext:unsafe-mode was added as a debugging tool to temporarily
remove restrictions on privileged APIs. But as it turns out, there
are now extensions that toggle the property permanently. Right now
none of them are malicious (as far as I can see), but it's still a
bad idea and should be discouraged.
Do this with a notification that warns the user when unsafe mode is
enabled non-interactively (i.e. via looking glass), and hopefully
also clarifies what the weird lock icon in the top bar is about.
magnifier: Remove call to dropped Clutter::get_default_frame_rate()
Clutter::get_default_frame_rate() has been removed in mutter!2002, but
it is still being used here. Given that this was basically hardcoded to
60 in mutter with the only way of changing this being an obscure
environment variable, just use that value here directly. This avoids a
crash when starting gnome-shell with the magnifier enabled.
libgnome-bluetooth will start to offer a 2.0 library version
depending on GTK4. Given that GNOME Shell already depends on
GTK3, it cannot use this next version of gnome-bluetooth. And
since GJS will automatically try and use the latest version
available of any library, Shell must specify it wants 1.0
explicitly.
Add a required GnomeBluetooth version number when importing it
for the status indicator.
magnifier: Disable desaturation effect when not in use
The desaturation effect was always enabled, regardless of the specified
factor. This was causing the magnifier to always hit offscreen
rendering, even when not necessary. Additionally offscreen rendering is
currently also causing glitches in MetaWindowGroup which this helps to
avoid in some cases.
Carlos Garnacho [Fri, 29 Oct 2021 14:46:18 +0000 (16:46 +0200)]
inputMethod: Do not reset invisible preedit on focus_out
If the preedit is in invisible state, the last preedit string that
was sent around is already null, so there is no need to clear the preedit
in that case.
Carlos Garnacho [Fri, 29 Oct 2021 14:43:15 +0000 (16:43 +0200)]
inputMethod: Do not communicate preedit text change on reset
This is now done in the ClutterInputFocus for us, since
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1940. There
is no need to duplicate this call, and it happens to cause undesired
scrolling to content in some cases when this reset happens during
a change in the IM focused client state.
Florian Müllner [Tue, 26 Oct 2021 17:40:08 +0000 (19:40 +0200)]
dbusServices/extensions: Only allow one dialog at a time
Showing multiple preference dialogs at the same time (for instance
by repeated `gnome-extensions prefs` calls) may or may not work as
expected, depending on whether any of the dialogs is modal or not
(read: opened via the Extensions app).
The easiest way to address this is to disallow more than a single
dialog at the time. It's arguably also the more predictable behavior,
and means extensions don't have to deal with inconsistent state
caused by multiple dialogs.
Florian Müllner [Thu, 28 Oct 2021 17:27:57 +0000 (19:27 +0200)]
dbusServices/extensions: Fix shutdown after showing prefs
GTK4 relies entirely on refcounting for cleanup (that is,
there is no longer a destroy() method that forces a dispose
run regardless of the refcount).
Unfortunately that makes cleanup harder in (some) language
bindings, where an object may be kept alive implicitly by
closures etc.
Address this by releasing the hold count when the window
is closed rather than when it is destroyed.
This isn't the most elegant, but it ensure that the service
doesn't get stuck if an extension doesn't carefully clean
up everything in its prefs widget.
Florian Müllner [Thu, 28 Oct 2021 17:55:23 +0000 (19:55 +0200)]
extensions-tool/prefs: Log D-Bus errors
We currently ignore any error that may occur when calling the
OpenExtensionPrefs D-Bus method. Right now such an error is highly
unlikely, given that we already checked that we are running under
gnome-shell and the extension in question exists and has prefs.
We'll soon make sure that only one dialog is shown at any time,
which is an error that we can realistically expect, so handle that
properly.
Sebastian Keller [Sat, 30 Oct 2021 11:21:17 +0000 (13:21 +0200)]
shell/app: Don't move all workspace windows to their startup workspace
Windows from some applications, such as guake, are created as showing on
all workspaces. When these windows are put on the workspaces via
set_workspace_state() during construction, the first time the window is
added to a workspace in the loop triggers the shell app tracker which
then tries to move the window to its startup workspace. This makes the
window unsticky which triggers another set_workspace_state() which
tries to remove the window from all workspaces, but currently it is only
on the first one and then adds it to the startup workspace. Once that is
finished, the first set_workspace_state() continues adding the window
to the remaining workspaces, despite the window now no longer having
on_all_workspaces set to true.
When the window is now unmanaged, the window according to its internal
state is only found on the startup workspace, so it will only be removed
from that. This causes the assertion to fail that checks that the window
is no longer present on any workspace after this.
projects / gnome-shell.git / log